Integrated systems for electronic bill presentment and payment

ABSTRACT

The present invention relates generally to electronic commerce, and more particularly to methods and systems for integrating electronic bill presentment and payment among biers, consumers, banks and other financial institutions, electronic payment facilitators, and web portals and other spaces able to support an interface for presentment and/or payment of bills.

The present invention relates generally to electronic commerce, and moreparticularly to methods and systems for integrating electronic billpresentment and payment among billers, consumers, banks and otherfinancial institutions, electronic payment facilitators, and web portalsand other spaces able to support an interface for presentment and/orpayment of bills.

BACKGROUND OF THE INVENTION

Billing consumers for goods and services has always been a necessaryexercise and transaction cost of engaging in credit-based commerce.Traditionally, businesses bill consumers for goods and services bygenerating and mailing paper bills or invoices. There are many obviousbusiness concerns relative to paper-based billing. Companies utilizingpaper-based billing do so at a substantial cost. For example, a companywith 100,000 accounts which are billed on a monthly basis may spend overtwo million dollars a year in paper-based billing expenses. Much of thisexpense stems from the cost of materials, postage, and manual processingof the paper bills, inserts, and envelopes.

Other significant logistical and business concerns detract from thepaper-based billing option. The time delay associated with sending billsand receiving payments via conventional mailing deprive companies of thetime value of money and therefore create additional transactional costs.This time delay is particularly troublesome to small billers andnon-recurrent billers who tend to rely more heavily on cash How.

Paper-based billing can also deprive billers of an opportunity to buildbrand. Although many paper billers include various types of marketinginserts with their bills in an attempt to use the billing activity as anadditional opportunity to make favorable brand impressions on theconsumer, those materials cannot be targeted as effectively as in aninteractive session. For instance, billers do not have significantrealistic control over the circumstances under which, or whether, aconsumer views particular inserts. Indeed, studies have shown that manyconsumers disregard such inserts altogether.

The development of the internet creates new opportunities to transactbusiness electronically, including to conduct the billing presentmentand payment process electronically, in an on-line way or otherwise. Somerefer to various aspects of the electronic billing process as electronicbill presentment and payment (EBPP). Instead of mailing paper bills,EBPP enables businesses to publish, distribute and/or present billselectronically on web pages. Instead of writing checks and applyingstamps, consumers have the opportunity to pay bills by an electroniccredit card charge or direct bank draft. The biller benefits by avoidingthe cost of generating and mailing paper bills, and by avoiding thepayment float occasioned by two-way mail delay and other delays inpaper-based remittance. The consumer benefits with the added convenienceof conducting transactions online, and the opportunity to pay many orall bills on one site or in one virtual space.

In practice, however, there are significant concerns with conventionalapproaches to EBPP, For example, in one common approach to EBPP, whichis often referred to as the custom development method, billers create aproprietary electronic billing system and fink it to a third-party forpayment processing. Because custom development is mostly an internalEBPP solution, it gives biers the advantage of tight control over thebilling system. However, this type of solution is very costly. Not onlyis it a technology risk because bitters lose the flexibility to adapt toother EBPP standards, but it requires a substantial amount of manpowerand infrastructure. Furthermore, such systems innately discourageconsumer use or popularity, since the consumer is required to log ontoand initiate a session on a separate site for each different bill theconsumer wishes to pay.

A second common EBPP approach, which is referred to as the consolidatedapproach, presents its own set of problems. This method of enabling EBPPtrades control of the billing interface and branding opportunity for areduction in cost, risk, and infernal staffing by outsourcing the EBPPto a third party consolidator. Here, the electronic payment processorlakes on a lock box function of holding and moving cash during billingand payment. The payment processor performs an aggregation function bypresenting multiple billers' statements at a single, consolidating website. Not only does interposition of the consolidator and its interfacebetween tellers and consumers interrupt any existing relationship, butit also precludes exploitation of new biller opportunities to interactwith consumers.

In addition to the problems already mentioned, existing EBPP enablingmethods have various other disadvantages. For example, they remain anexpensive option for most billers who lack sufficient economies of scalenecessary to overcome the high fixed cost of implementation. These EBPPmethods, which primarily focus on reducing biller costs, also often fallto address the issue of consumer convenience adequately, much less toprovide effective incentives for consumer adoption.

Furthermore, conventional EBPP approaches, which seek to implement EBPPon portal interfaces, often require redundant resources supported bymultiple entities and consequently waste processing and transportresources. For example, using existing EBPP methods, if a consumerdesires to pay AT&T bills electronically at a website such asYahoo.com., the following occurs. First, the consumer requests thatYahoo.com receive the AT&T bill and send it to the consumer. Then,assuming AT&T partners with an electronic payment facilitator such asCheckFree, Yahoo.com makes a request to CheckFree. Finally, CheckFreeinitiates the request to AT&T. Because each of these entities areindependent, each requires its own resident database and other supportfunctionality. Such conventional portal-supported EBPP approachesprovide significant opportunity for improvement.

SUMMARY OF THE INVENTION

The present invention provides fully integrated, end-to-end electronicbill presentment and payment systems. Such systems support integratedEBPP access and functionality for billers, consumers, banks, otherfinancial institutions, and other electronic payment facilitators, anyor ail of which can be transacted at a web portal, web site or otherinterface or virtual space (“Portal Interface”). Such systems cansupport such activities at multiple portals so that consumers and othershave the choice of paying bills and accomplishing other EBPPtransactions in whatever virtual space or at whatever site they desire.The systems provide consumers, billers and others the ability toself-enable EBPP by interacting with the portal interface such as via aseries of web pages. Such systems of the present invention can controlall interactions between billers and consumers from the portalinterface. In addition, the systems can seamlessly orchestrate all othertransactions with payment facilitators and banks. Therefore, all EBPPfunctionality and processes can be controlled by systems and processesaccording to the present invention.

The Portal Interface controlled by systems of the present inventionprovides individual consumers with a secure personalized electronic billportfolio where they can schedule, view, and pay their electronic bills.The Portal Interface controlled by such systems also enables billers tocreate consumer accounts and electronically publish their bills on apersonalized electronic bill portfolio for viewing and payment. Thesystems can provide all bill processing, payment processing, consumerand biller data storage, and arrange all external billing transactions.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing external connectivity of a preferredembodiment of integrated electronic bill presentment and payment systemsof the present invention.

FIG. 2 is a block diagram illustrating the architecture of a preferredembodiment of integrated electronic bill presentment and payment systemsof the present invention.

FIG. 3 is a block diagram illustrating general functionality of acustomer-related portal interface supported by a preferred embodiment ofintegrated electronic bill presentment and payment systems of thepresent invention.

FIG. 4 is a block diagram illustrating general functionality of abiller-related portal interface supported by a preferred embodiment ofintegrated electronic bill presentment and payment systems of thepresent invention.

FIG. 5 is a sign in screenface of a portal interface generated by apreferred embodiment of systems of the present invention.

FIG. 6 is a help screenface of a portal interface generated by apreferred embodiment of systems of the present invention.

FIG. 7 is an inbox screenface of a portal interface generated by apreferred embodiment of systems of the present invention.

FIG. 8 is a bill summary list screenface of a portal interface generatedby a preferred embodiment of systems of the present invention.

FIG. 9 is a company list screenface of a portal interface generated by apreferred embodiment of systems of the present invention.

FIG. 10 is an add a company screenface of a portal interface generatedby a preferred embodiment of systems of the present invention.

FIG. 11 is a my outbox screenface of a portal interface generated by apreferred embodiment of systems of the present invention.

FIG. 12 is a pay accounts screenface of a portal interface generated bya preferred embodiment of systems of the present invention.

FIG. 13 is a preferences screenface of a portal interface generated by apreferred embodiment of systems of the present invention.

FIG. 14 is a change password screenface linked off the preferencesscreenface of a portal interface generated by a preferred embodiment ofsystems of the present invention.

FIG. 15 is a personal information screenface linked off the preferencesscreenface of a portal interface generated by a preferred embodiment ofsystems of the present invention.

FIG. 16 is payment reminder creation screenface linked off thepreferences screenface of a portal interface generated by a preferredembodiment of systems of the present invention.

FIG. 17 is a generic create a reminder screenface linked off thepreferences screenface of a portal interface generated by a preferredembodiment of systems of the present invention.

FIG. 18 is a contact customer service screenface linked off thepreferences screenface of a portal interface generated by a preferredembodiment of systems of the present invention.

FIG. 19 is a biller signup screenface of a portal interface generated bya preferred embodiment of systems of the present invention.

FIG. 20 is a bill template design step 1 screenface of a portalinterface generated by a preferred embodiment of systems of the presentinvention.

FIG. 21 is a bill template design step 3 screenface of a portalinterface generated by a preferred embodiment of systems of the presentinvention.

FIG. 22 is a bill template design step 2 screenface of a portalinterface generated by a preferred embodiment of systems of the presentinvention.

FIG. 23 is an invoice creation step 1 screenface of a portal interfacegenerated by a preferred embodiment of systems of the present invention.

FIG. 24 is an invoice creation step 2 screenface of a portal interfacegenerated by a preferred embodiment of systems of the present invention.

FIG. 25 is an invoice preview screenface of a portal interface generatedby a preferred embodiment of systems of the present invention.

FIG. 26 is a report builder screenface of a portal interface generatedby a preferred embodiment of systems of the present invention.

FIG. 27 is a reports screenface of a portal interface generated by apreferred embodiment of systems of the present invention.

FIG. 28 is an upload bills screenface of a portal interface generated bya preferred embodiment of systems of the present invention.

FIG. 29 is bill quality assurance screenface of a portal interfacegenerated by a preferred embodiment of systems of the present invention.

FIG. 30 is a second bill quality assurance screenface of a portalinterface generated by a preferred embodiment of systems of the presentinvention.

FIG. 31 is a third bill quality assurance screenface of a portalinterface generated by a preferred embodiment of systems of the presentinvention.

FIG. 32 is an add an account screenface of a portal interface generatedby a preferred embodiment of systems of the present invention.

FIG. 33 is a send customer e-mail screenface of a portal interfacegenerated by a preferred embodiment of systems of the present invention.

DETAILED DESCRIPTION OF THE INVENTION A. General Overview of System

FIG. 1 shows connectivity of a preferred embodiment 10 of integratedelectronic bill presentment and payment systems (“systems”) of thepresent invention. System embodiment 10 interfaces with, among otherexternal entities, billers 12, which may include very small andnon-recurrent billers 14, banks and other financial institutions 16,payment facilitators 18, web portals and bill presenters 20, andconsumers 22. System embodiment 10 shown in FIG. 1 is implemented on aSun platform using an Oracle database with other programs that allowconnectivity via any desired network or transport infrastructurepreferably the internet, to a portal interface in spaces 20 via anExtensible Markup Language or other standard markup or other common datainterchange model or language. Portal interfaces 15 may be implementedin Hypertext Markup Language or as otherwise desired to operate onbrowsers, whether or not applet enabled, or as otherwise desired.

FIG. 2 shows an architecture diagram for a preferred embodiment 10 ofsystems according to the present invention. System embodiment 10supports a portal interface 15 which allows consumers 22 and billers 12and/or 14 the ability to self-enable EBPP by interacting with a seriesof web pages or other interfaces or presentations of whatever desireddesign or type on a web portal 20 or at any other location in actual,electronic or virtual space, supported by the global informationinfrastructure, successor systems, private systems or any othercommunications network or system. System embodiment 10 can enable allEBPP functionality via the portal interface 15. System embodiment 10 cancontrol all interactions or transactions between billers 12 and/or 14and consumers 22 using portal interface 15 as the communications and/orpresentation medium. System embodiment 10 can also arrange all othernecessary transactions with payment facilitators 18 and banks 18.

System embodiment 10 may be created to allow consumers 22 to definewhatever portal or any other location or space they desire to accesssystem embodiment 10. This can be any web portal 20 or other billpresentment web site, such as Yahoo.com® or GO2Net®. In order toinitialize a bill portfolio, consumers 22 can go to the selected webportal or other space 20. System embodiment 10 prompts consumers 22 forpersonal information sufficient for authentication. System embodiment 10can be adapted only to assign consumers 22 a secure bill portfolio whenconsumers 22 can be authenticated by a third party credit verifierservice. After being verified, a consumer bill portfolio may be accesscontrolled by any desirable schema or paradigm, including by using abill portfolio identification number, a unique consumer identificationnumber, and an encryption key defined by consumers 22. Consumers 22 mayalso define multiple accounts at the same bill portfolio.

FIG. 3 illustrates the general functionality of a preferred embodimentof a consumer portal interface supported by system embodiment 10. Systemembodiment 10 provides consumers 22 a secure personalized portfolio forviewing and paying electronic bills that are input into systemembodiment 10 by various billers. System embodiment 10 directs allincoming electronic bills to the bill portfolio of consumers 22.Consumers 22 also have the option of notifying paper-based billers thatthey desire to have bills presented electronically. System embodiment 10can notify the billers and initiate electronic scanning of paper bills.Consumers 22 may access the portfolio at any location of choice usingany interface, such as, for instance, a conventional web browser, otheronline device, any wireless device, or any other device which maycommunicate with system embodiment 10 in any manner. Any such device isa candidate to support presentation of or transaction with portalinterface 15 by consumers 22. Consumers 22 can also define the format ofthe billing information. For example, the billing data may be suppliedto consumers 22 in a variety of standard accounting formats.

System embodiment 10 also enables consumers 22 to pay electronic billsvia credit card, ACH, or electronic funds transfer or using any othermode or medium of payment or reconciliation. System embodiment 10 canalso support payments between different consumer bill portfolios. Inaddition, system embodiment 10 can provide for various types ofcommunication between or among billers 12 and/or 14 and consumers 22 andbetween or among consumers 22.

FIG. 4 illustrates the general functionality of a preferred embodimentof a biter interface in accordance with the present invention withsystem embodiment 10. Billers 12 and/or 14 may self-enable EBPP byaccessing system embodiment 10. System embodiment 10 can obtaininformation from billers 12 and/or 14 and authenticate by a creditverifier service if desired. After a biller is authenticated, systemembodiment 10 enables billers 12 and/or 14 to define the presentation ofthe bill, among other things. Billers 12 and/or 14 may also do suchthings as customize bill templates, upload logos, addresses, and definebill fields. System embodiment 10 may support billers 12 and/or 14carrying out any desired or desirable task, such as specifying marketingmessages that are defined by consumer specific rules, set up consumers22 to bill and/or set up specialized consumer groups based on predefinedrules.

Billers 12 and/or 14 can also specify various other bill generationcriteria. The bill criteria can accommodate criteria such as whether thebill is for a fixed amount or whether it is formula based. Billers canalso speedy the bill schedule.

Billers 12 and/or 14 may bill consumers 22 by inputting any bill data.System embodiment 10 enables billers 12 and/or 14 to predefine how theelectronic bill is to be displayed. System embodiment 10 also managesthe routing of the bills. System embodiment 10 selects thebiller-defined delivery channel, which could be either paper orelectronic. If a bill portfolio exists, the bill is placed in it. If thebilled consumer 22 does not have a bill portfolio, electronic deliveriescan be sent via email along with a message notifying consumer 22 thatthe biller is using electronic billing. If neither exists, systemembodiment 10 can perform standard paper billing. System embodiment 10may also enable billers 12 and/or 14 to identify conventional mailingaddresses for consumers 22 so that consumers 22 may enable standardpaper billing. System embodiment 10 may also provide notification tobillers 12 and/or 14 when bills are rejected, bills are overdue, orpayments are received.

B. Consumer Interface to System

FIGS. 5-18 show web images of a preferred embodiment of a consumerportal interface on a web portal controlled by system embodiment 10. Asmentioned above the interface 15 can appear on any device in anyfunction in actual electronic or virtual space, using any network orcommunications system, use of the web and browser paradigm for thefollowing description is merely one example and should not beinterpreted to limit the invention or its scope in any way. That said,FIGS. 5 and 8 show web pages for the initial welcome screens for a webportal 20 of system embodiment 10. As any other web site or web portal20 on the Internet, the welcome screen and all linked web pages on webportal 20 are freely accessible to billers 12 and/or 14 and consumers 22using any standard web browsing software and computer. Consumers 22 mayalso access the web pages by using any device of whatever stripe, suchas a personal digital assistant, a cellular phone, or pager, whichsupports internet access via wireless technology, standard telephonedial-up or network connections, or any communications system. Thewelcome screen permits new billers 12 and/or 14 and consumers 22 tocreate a new account. When setting up a new account, billers 12 and/or14 and consumers 22 are required to input personal information that canbe used to identify and authenticate the user for subsequent sessions.After the user inputs the personal information, the system can contest acredit verifier company, such as Equifax® or TRW®, and uses a creditreport supplied by the company to automatically determine whether theuser meets certain predetermined requirements, in which case a newaccount may be created.

After creating an account the welcome screen permits new consumers 22 tocreate a new personalized bit portfolio or additional bill portfolios.Some sophisticated consumers 22 may desire to have separate billportfolios with the same account for multiple homes, separateindividuals within a home, or for a separate business. After a billeraccount is established, new billers 12 and or 14 may access thefunctionality, which is discussed below.

The welcome screen also permits billers 12 and/or 14 and consumers 22that have already registered to access system embodiment 10 by inputtinga user identification number, a personalized password, and an encryptionkey. These user specific identifiers ensure that only registered usersthat have been authenticated are granted access to personal informationstored on system embodiment 10.

FIGS. 7-18 show a series of web pages for a personalized bill portfoliomanagement system that registered consumers 22 use to access andinteract with a bill portfolio via portal interface 18. FIG. 7 shows anincoming bill web page that enables consumers 22 to interact with allincoming electronic bills including electronic bills that have beenreceived but remain unpaid and paper bills that have been received andscheduled for electronic presentment. For each bill, the web pagedisplays the biller's name, the amount due, the date payment is due, andthe status of the bill. Consumers 22 may also select and view eachelectronic bill. FIG. 8 shows a web page displaying a sample billsummary and payment information. The incoming bill web page also permitsconsumers 22 to select and electronically pay particular bills.

System embodiment 10 enables consumers 22 to notify paper billers thatthey desire to have bills presented electronically. System embodiment 10can contact the paper-based biller and notify the biller that theirelectronic bills may be presented to consumers via system embodiment 10.If the biller declines, system embodiment 10 can arrange to have thepaper bill scanned into system embodiment 10 where it can be viewed andpaid by consumers 22 using system embodiment 10. Paper bills that havebeen received and are being processed for scanning and electronicpresentment are displayed on the incoming bill web page as “scheduled”.System embodiment 10 may also enable billers 12 and/or 14 to identifyconventional mailing addresses for consumers 22 so that consumers 22 mayenable standard paper billing.

FIG. 9 shows a biller list web page that enables consumers 22 to listthe companies whose bills they desire to pay electronically. For eachbiller 12 and/or 14, the web page displays the company name, acorresponding identification number, and whether or not the company hasbeen scheduled for electronic bill presentment and payment. Consumers 22may also use the web page to modify the configuration for a biller 12and/or 14 or to delete a biller 12 and/or 14 from the list altogether.FIG. 10 shows a web page that enables consumers 22 to add additionalbillers 12 and/or 14 for electronic bill presentment and payment. Theweb page has a series of pull down menus enabling a consumer 22 todefine a biller configuration. One menu allows the consumer 22 to definea particular category for the biller 12 and/or 14. For example,consumers 22 may categorize billers 12 and/or 14 as a utility biller,telecommunications service biller, credit card biller, professionalservices biller, or any other category of relevance to the consumer.Another menu allows the consumer 22 to select a bill delivery methodsuch as CheckFree® or any other third party electronic paymentfacilitator 18. Other menus permit the consumer 22 to input the accountnumber for the biller 12 and/or 14, as well as an expiration date.Consumers 22 may also elect to enable functionality permitting arecurring payment schedule.

FIG. 11 shows an outgoing bill web page that enables consumers 22 tointeract with electronic bills that have already been paid. Similar tothe incoming bill web page, the outgoing bill web page displays thebiller's name, the amount due, the date payment is due, and whether ornot the bill has been paid. Consumers 22 may also select and view a billsummary and payment information screen for a particular bill. Finally,consumers 22 may select and delete bills that have already been paid.

FIG. 12 shows a payment accounts web page that enables a consumer 22 toview, add, modify, and delete credit card or debit card accounts thatthe consumer 22 desires to use for electronic payment of bills. For eachpayment account the consumer 22 is required to input an account type, anaccount number, an account name, expiration date, and the name appearingon the card.

FIG. 13 shows a consumer preferences web page that enables the consumer22 to personalize a bill portfolio. FIGS. 14 and 15 show web pages thatenable consumers 22 to view and modify personal information associatedwith a bill portfolio and a personalized password for accessing a billportfolio. The web page also enables consumers 22 to initialize emailnotification of when bills are presented to a bill portfolio forpayment. Consumers 22 may also create generic reminders or bill paymentreminders, which may be sent directly to an email address.

FIGS. 16 and 17 show web pages for creating and scheduling genericreminders and payment reminders. The web pages enable consumers 22 tospecify when the reminder will begin to be sent, how often the reminderwill be sent, at what time the reminder will be sent, and when to stopsending the reminder. For generic reminders, the consumer 22 can berequired to specify recipients of the reminder and the content of themessage.

At any time while logged into system embodiment 10 and accessing a billportfolio, consumers 22 may contact consumer service by using a consumerservice web page as shown in FIG. 18. The consumer service web page alsolists a variety of contact information, as welt as links to answers tofrequently asked questions.

The pages described above and shown in FIGS. 5-18 are merely exemplary.In a first sense, each or any of them may contain additional fields, ormay contain fewer fields, to solicit or require information of any typeor sort, or to allow consumers 22 to interact with system embodiment 10in any way for the purpose or result of bill payment or reconciliation.In a second sense, other pages may be employed for such results orpurposes, or any of the above-mentioned pages may be omitted. Again,these pages are merely one example of an embodiment of a portalinterface that can support system embodiment 10 on any platform ordevice anywhere in actual, electronic or virtual space.

C. Biller Interface to System

FIGS. 19-33 show a series of web pages that billers 12 and/or 14 may useto self-enable EBPP. (As mentioned above, the interface 15 can appear onany device in any location in actual, electronic or virtual space, usingany network or communications system; use of the web and browserparadigm for the following description is merely one example and shouldnot be interpreted to limit the invention or its scope in any way.) Anytype of biller 12 and/or 14 may use system embodiment 10 to self-enableEBPP, but it is particularly advantageous to billers 14 with arelatively small number of consumers, as well as billers 14 withnon-recurring consumers. FIG. 19 shows a registration web page forsigning up to use system embodiment 10 for EBPP. Billers 12 and/or 14can enter a series of information text boxes on the web page, whichinclude a merchant identification number. System embodiment 10 can thencontact a credit verifier and access a credit report supplied by thecredit verifier to automatically determine whether the bier 12 and/or 14is authenticated. If the biller 12 and/or 14 is authenticated, systemembodiment 10 automatically notifies the biller 12 and/or 14 and accessto system embodiment 10 is granted.

As described above, once registered and authenticated biers 12 and/or 14may access system embodiment 10 by inputting a user identificationnumber, a personalized password, and an encryption key. FIGS. 20-22 showweb pages that enable billers 12 and/or 14 to define the layout of anelectronic bill. FIG. 20 shows a web page for choosing a predefinedtemplate provided by system embodiment 10. FIG. 21 shows a web page thatenables billers 12 and/or 14 to interactively design their own billtemplate. Once the layout of the bill is defined, billers 12 and/or 14can specify what type of software program they will use to provideconsumer billing data to system embodiment 10. In the preferredembodiment of the invention, system embodiment 10 supports billing dataof any type, such as, for example, data formatted to comply with overthe counter software accounting packages such as QuickBooks® andPeachtree®, or billing data formatted as a printer datastream or adatabase export. FIG. 22 shows a web page for billers 12 and/or 14 toselect the appropriate billing data format.

In situations where creating a bill template is not manageable, as forone time transactions with a consumer 22, system embodiment 10 canenable billers 12 and/or 14 to send a one time only invoice. FIGS. 23-25show web pages that enable this functionality. Billers 12 and/or 14 canbe required to include the biller's name, the amount due, a descriptionof the goods or services, the recipient of the invoice, the number ofthe bill portfolio where the invoice is to be sent, and the date paymentis due. After inputting the required invoice information, systemembodiment 10 preferably permits the biller 12 and/or 14 to preview theinvoice as it will appear in the consumer's bill portfolio and send it.

System embodiment 10 can also enable billers 12 and/or 14 to createvarious reports. Billers 12 and/or 14 may create reports showing any ofa number of transactional statistics, such as the number of bills paid,the number of bills sent, the number of bills disputed, the number ofbills partially paid, the number of bills published, the number of billsnot published, and/or the number of bills that have been reviewed forquality assurance. FIGS. 26 and 27 show web pages enabling billers 12and/or 14 to create and schedule reports.

System embodiment 10 can also enable billers 12 and/or 14 to uploadbills from a consumer's bill portfolio. FIG. 28 shows a web page thatenables billers 12 and/or 14 to do this. Billers 12 and/or 14 may searchfor a particular consumer 22 by name or may sort for a number ofconsumers 22 in a predefined group. System embodiment 10 performs therequested query and then displays each of the bills in the consumer'sbill portfolio that are associated with the biller. Billers 12 and/or 14may also select and preview a particular bill. FIG. 29 shows a web pagefor previewing the bill of consumers 22. From the preview screen,billers 12 and/or 14 may edit the bill, send the bill, or defer sendingthe bill until later. FIG. 30 shows a web page that enables a biller 12and/or 14 to edit a consumer's bill.

As shown in FIG. 31, system embodiment 10 can also enable billers 12and/or 14 to add, modify, or delete consumer accounts. Billers 12 and/or14 may add a consumer account or choose the account organizer byselecting the appropriate link on the web page. FIG. 32 shows the linkedweb page where a biller 12 and/or 14 may input a new client's name,account number, email address, and attribute. System embodiment 10 mayalso enable billers 12 and/or 14 to identify conventional mailingaddresses for consumers 22 so that consumers 22 may enable standardpaper billing. The attribute field can be used in combination with theaccount organizer to define groups of consumer accounts to simplify billgeneration and delivery. Billers 12 and/or 14 may use consumer groups todefine and generate bills without the need for repetition. For example,when creating a list of consumer accounts, a biller 12 and/or 14 mayassign a specific zip code attribute to a group of accounts, which wouldenable the biller 12 and/or 14 to generate and deliver all bills of thespecific zip code at the same time.

As shown in FIG. 33, at any time while logged into system embodiment 10billers 12 and/or 14 may send emails to a consumer's bill portfolio.Billers 12 and/or 14 can use this functionality for payment reminders,marketing notices and offers, or any other advantageous use.

The pages described above and shown in FIGS. 19-33 are merely exemplary.In a first sense, each or any of them may contain additional fields, ormay contain fewer fields, to solicit or require information of any typeor sort, or to allow billers 12 and/or 14 to interact with systemembodiment 10 in any way for the purpose or result of bill presentmentor to effectuate payment or reconciliation, in a second sense, otherpages may be employed for such results or purposes, or any of theabove-mentioned pages may be omitted. Again, these pages are merely oneexample of an embodiment of a portal interface that can support systemembodiment 10 on any platform or device anywhere in actual, electronicor virtual space.

The foregoing is provided for purposes of disclosure of a preferredembodiment of the present invention. Additions to, deletions oromissions from, or changes to interfaces, systems, or embodimentsdisclosed above may be accomplished; so long as they help carry out theresults or purposes of providing systems that support interfaces toeffectuate EBPP, they remain within the scope or spirit of theinvention.

1-21. (canceled)
 22. A method, comprising: receiving, via a bill dataprocessor, bill data relating to a plurality of bills from a pluralityof billers, the bills being associated with a plurality of consumershaving consumer terminals; converting, via the bill data processor, thebill data into a format compatible with a database; and storing, via thebill data processor, the converted bill data in the database;authenticating, via a bill report processor, merchant identificationnumbers received from billers; upon authentication, providing, via thebill report processor, a report to a biller, the report including datarelating to a status of bills corresponding to the bill data stored inthe database; granting access, via a bill security processor, to thedatabase upon receipt of encrypted access information; and in responseto instructions received from a selected one of the consumer terminals,creating, via a portal interface implemented on a platform separate fromthe consumer terminals and configured by instructions received from theconsumer terminals, at least two bill portfolios for the selected one ofthe consumer terminals, the two portfolios corresponding to differentaspects of a financial profile of a consumer associated with theselected one of the consumer terminals; upon receipt of a request fromthe selected one of the consumer terminals, transmitting, via the portalinterface, signals to the selected one of the consumer terminals tocause display of an electronic bill representing a selected bill; uponreceipt of instructions from the selected one of the consumer terminals,initiating, via the portal interface, payment of the selected bill; andupdating, via the portal interface, information in the database withpayments information.